Bun.build: set BuildArtifact.sourcemap from source_map_index, not from the next output by robobun · Pull Request #33588 · oven-sh/bun

robobun · 2026-07-07T01:43:44Z

Fixes #37184

Problem

BuildArtifact.sourcemap is the next element of outputs, not the output's map. With two entry points, a.js.sourcemap is b.js. With a CSS import, it is the CSS asset.
console.log of an output prints each later chunk under it, through .sourcemap.
on_complete (src/runtime/api/js_bundle_completion_task.rs) stored the next wrapper as .sourcemap. The list order is [chunks, maps and bytecode, additional files].

Fix

on_complete walks the list last to first and stores the wrapper at source_map_index. A map comes after its file, and every other reader uses the field as a position.
do_compilation removes files from the list and now gives the executable its map's new position.
Verified: 22 new tests in test/bundler/bun-build-api.test.ts and 2 in bun-build-compile-sourcemap.test.ts fail on main. Also standalone.test.ts, bundler_html.test.ts.
Self-reviewed: 7 concerns raised, 7 addressed.

Background

An OutputFile is one file of a build. source_map_index is the position of its map in the same list, or u32::MAX.
A BuildArtifact is the JS wrapper of an OutputFile. Only on_complete fills .sourcemap.
Considered a second loop and an index table (this PR's first version): one more pass per build, one allocation per compile build.

Downsides

Each output with a map costs one more getDirectIndex call (0 to 1). Allocations do not change. The release binary grows by 256 bytes.
.sourcemap and the printed text of an output change for builds with two or more chunks. A stored snapshot of that text must be regenerated.

Notes

Measurements (linux-x64. Debug build for counts, release bun-profile for sizes. Main af566a38e5 against the same commit with this diff.)

.sourcemap pairings wrong: 45 of 53 map-owning outputs on main, 0 of 53 with this diff. 33 configurations: one entry, two entries, two entries + splitting, a JS entry that imports CSS, an HTML entry, bytecode with two entries, dts with two entries (each with linked and external, with and without outdir), then compile, compile + splitting, compile + a CSS import, compile with [index.html, x.ts] and with [x.ts, index.html].
Calls inside on_complete on the JS thread (gdb breakpoint hit counts, three runs each, all identical), as getDirectIndex / getIndex / setInternalField / putIndex:
- one entry, no map: 0/0/0/1 to 0/0/0/1
- one entry, linked map: 0/0/1/2 to 1/0/1/2
- two entries, external maps: 0/0/2/4 to 2/0/2/4
- compile + splitting + external maps: 0/0/1/3 to 1/0/1/3
Rust allocations inside on_complete (__rust_alloc / __rust_dealloc hit counts, same runs): 5/1, 8/2, 14/4 and 72/73, before and after. The diff adds no loop over output_files.
Release text: 137,959,399 to 137,959,655 bytes (llvm-size). on_complete: 19,197 to 19,470 bytes (llvm-nm --print-size). generate_chunks_in_parallel does not change (39,904 bytes).
Live BuildArtifact cells while one output of an 8-entry build with external maps is held: 9 to 2 (heapStats() after Bun.gc(true)). On main each output kept the next output alive through .sourcemap. Protected BuildArtifact count: 0 to 0.
Printed output, 64 entry points given as ./eN.js from the working directory, sourcemap: "external": Bun.inspect(outputs[0]) is 49,621 characters with 64 artifacts under it on main, and 364 characters with 1 artifact with this diff. Bun.inspect(outputs) is 1,269,191 to 31,940 characters. A build with one entry prints the same text before and after.

Other changes in the diff

compile with entry points [index.html, app.js] was wrong on main: the executable's .sourcemap was the map of the page chunk. The other compile shapes were correct on main only because the executable's map was the next element. The existing tests for compile and for compile + splitting now assert the pairing.
If the executable's own map cannot be written, its .sourcemap is null. On main it was the map of another chunk. The new test puts a directory at the path of the map. The build reports success: true and prints the write error to stderr, as on main.
do_compilation also clears bytecode_index and module_info_index on the executable, because the same compaction removes those files. Only StandaloneModuleGraph.rs reads these two fields, before the compaction.
The standalone HTML filter in generateChunksInParallel.rs keeps HTML files and maps. A debug_assert! states that none of them names another file by position, so there is nothing to remap. Failure path, checked once by hand: with the filter changed to keep every file, a standalone page build with external maps panics with "a kept file names another file by its position before the filter".
on_complete has a debug_assert! that a source_map_index names a later file of kind sourcemap. Failure path, checked once by hand: with the remap in do_compilation disabled, compile + a CSS import panics with "output file 0 names 2, which is not a later Sourcemap file". A release build that finds a position that is not a map stores nothing, and .sourcemap is null.
The printer (BuildArtifact::write_format) follows .sourcemap with no depth limit. It stops after one level because a map has no .sourcemap. The kind check in on_complete keeps that true.
Two more mutations, each checked once by hand: a remap that records the position of a map that was not kept makes the new failed-write test fail, and no remap at all makes the compile + splitting test fail.
JSBundler.bind.ts declares sourcemap as BuildArtifact | null again. AOT: front end, test runs and tests for the rewritten compiler #47942 added undefined because the old code could store the undefined that to_js gives for a Noop file. The new code stores only the wrapper of a map.
OutputFile.rs gets one doc line on each of the three position fields.
compile: { aot: true } keeps one file, the main entry point's, as the executable. take_executable_file in compile_command/build.rs now clears its three positions when it truncates the list, so the debug_assert! in on_complete holds on this path too. .sourcemap of that output is null before and after.

Not changed

The readers that index output_files[source_map_index] directly (HTMLBundle.rs, StandaloneModuleGraph.rs, bake/production/mod.rs) are correct today.
referenced_css_chunks also holds positions and is stale after do_compilation. Nothing reads it after that point.
source_map_index stays a plain u32 position. Each place that removes files remaps it by hand (typed_files.rs, aot/assets.rs, aot/page_bundles.rs, aot/output.rs, and now do_compilation). A shared helper for all of them was considered. It changes code that is correct today, and it adds an allocation and two passes to each compile build.

History

The first version of this PR (July) used a second pass and an index table in do_compilation. It conflicted with main after BuildArtifact: drop redundant Strong for .sourcemap; use the wrapper's WriteBarrier slot #34668 removed the Rust-side sourcemap field and One termination signal, one fold: Err(Thrown) always means an exception is pending, and each event-loop dispatcher takes it in one place #37275 changed the promise.reject shape. This version keeps its two sites and its two-entry tests, and replaces the mechanism. The reviews and the two review threads of 2026-07-07 are about the first version.

Test runs on this machine (linux-x64, debug + ASAN)

The 24 new tests fail on a debug build of main and pass with this diff. The new tests in bun-build-api.test.ts also pass with BUN_JSC_validateExceptionChecks=1.
standalone.test.ts (26), bundler_html.test.ts (29), bun-build-api-dts.test.ts (8) and bundler_compile_splitting.test.ts (30) pass.
bun-build-api.test.ts: 114 pass. "can be called thousands of times" (180 s limit) times out with and without this diff.
bun-build-compile.test.ts: 74 pass, 7 time out in the full run. Three --bytecode tests also time out alone, with and without this diff. The other four pass alone.
The compile tests copy a 1.6 GB debug binary each. On this machine some of the older tests in bun-build-compile-sourcemap.test.ts pass the 5 s limit in one run and not in the next, with and without this diff.

no test proof · iteration 0 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/bundler/bun-build-compile-sourcemap.test.ts, test/bundler/bun-build-api.test.ts

…ti-entry builds The completion task assumed output_files was laid out [js, map, js, map, ...] and linked each JS output's .sourcemap to the next array element. OutputFileList actually lays them out as [chunks..., sourcemaps/bytecode..., additional...], so with 2+ entrypoints or splitting, a.js.sourcemap would be b.js and the last chunk got the first chunk's map. Each OutputFile already carries the absolute source_map_index into the array. Resolve .sourcemap from that index instead of next-element chaining.

coderabbitai · 2026-07-07T01:48:31Z

No actionable comments were generated in the recent review.

Walkthrough

The bundle completion task now tracks sourcemap positions through output compaction and associates each BuildArtifact with its indexed sourcemap. Executable-only output paths clear associated-file indices. Tests cover varied output ordering, build configurations, plugin callbacks, and failed map writes.

Changes

Sourcemap association refactor

Layer / File(s)	Summary
Sourcemap index tracking `src/runtime/api/js_bundle_completion_task.rs`, `src/bundler/OutputFile.rs`, `src/bundler/linker_context/generateChunksInParallel.rs`, `src/runtime/cli/compile_command/build.rs`	The completion task records the retained entry point’s sourcemap position. Executable-only output paths clear associated-file indices, and standalone-output filtering checks that retained files use sentinel indices.
Artifact association and validation `src/runtime/api/js_bundle_completion_task.rs`, `src/runtime/api/JSBundler.bind.ts`, `test/bundler/bun-build-api.test.ts`, `test/bundler/bun-build-compile-sourcemap.test.ts`	Output conversion runs in reverse order and resolves each artifact’s map through `source_map_index`. Tests cover linked and external maps, varied output ordering and types, plugin callbacks, and failed executable map writes. The declared `sourcemap` getter result excludes `undefined`.

Suggested reviewers: jarred-sumner, alii

Severity of issue fixed: Medium

Merge Risk: Minimal · up to 89c65

The reviewed sourcemap association paths show no outstanding issue requiring a fix before merge. Merge after normal checks.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the main change: assigning BuildArtifact.sourcemap using source_map_index.
Linked Issues check		[`#37184`] `on_complete` now uses `source_map_index` and assigns `.sourcemap` only when that position identifies a `Sourcemap`. It creates wrappers in reverse order so the map wrapper exists first. `do_…
Out of Scope Changes check		The changes stay within sourcemap and output-position correctness. Clearing stale indices when executable outputs are truncated, adding position assertions and documentation, and narrowing the TypeScr…
Description check		The description explains the problem, the fix, and how the author verified it, including test results. It does not use the template’s exact headings, but it provides the required information.

Full details: Linked Issues check

Explanation

[#37184] on_complete now uses source_map_index and assigns .sourcemap only when that position identifies a Sourcemap. It creates wrappers in reverse order so the map wrapper exists first. do_compilation remaps the entry point’s map position after compaction. The reported regression tests cover the single-entry CSS case and verify map pairings and null references when no map applies.

Full details: Out of Scope Changes check

Explanation

The changes stay within sourcemap and output-position correctness. Clearing stale indices when executable outputs are truncated, adding position assertions and documentation, and narrowing the TypeScript type to BuildArtifact | null support that behavior. The added tests cover these output and map relationships. No unrelated change is evident.

Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

Recent review info

Run configuration

Source mode: Auto

Repository: oven-sh/bun

Branch: farm/fbce87c4/fix-buildartifact-sourcemap-link

File: .coderabbit.yaml

Commit: 89c6522

Layers: Repository YAML

Review profile: ASSERTIVE

Plan: Advanced

Run ID: `0445214c-72d9-4250-91f7-a3a93b52f6ec`

Commits

Reviewing files that changed from the base of the PR and between `503a345` and `89c6522`.

Files selected for processing: 7

`src/bundler/OutputFile.rs`

`src/bundler/linker_context/generateChunksInParallel.rs`

`src/runtime/api/JSBundler.bind.ts`

`src/runtime/api/js_bundle_completion_task.rs`

`src/runtime/cli/compile_command/build.rs`

`test/bundler/bun-build-api.test.ts`

`test/bundler/bun-build-compile-sourcemap.test.ts`

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 1 remain after this review.

coderabbitai

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/runtime/api/js_bundle_completion_task.rs`:
- Around line 669-681: The source map lookup in
js_bundle_completion_task::do_compilation is using stale source_map_index values
after output_files is swap-compacted, which can cause chunks to attach the wrong
.map artifact when splitting is enabled. Update the compaction logic to
recompute and store new source_map_index values for kept entries, or thread an
old-to-new index map through the compaction and lookup path so the loop that
calls get_index on output_files_js always uses post-compaction indexes.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d3daec19-4065-4164-b947-5113e69904b5

📥 Commits

Reviewing files that changed from the base of the PR and between a780f57 and 503a345.

📒 Files selected for processing (2)

src/runtime/api/js_bundle_completion_task.rs
test/bundler/bun-build-api.test.ts

When compile is set, do_compilation keeps only the entry point and written sourcemaps and swap-compacts the array, but left each kept entry's source_map_index pointing at its pre-compaction position. With splitting that resolved the entry's .sourcemap to another chunk's map. Record an old-to-new index map during compaction and rewrite source_map_index on survivors; dropped targets remap to u32::MAX (no link). Adds .sourcemap assertions to the existing compile+external and compile+splitting tests to guard this path.

robobun · 2026-07-07T02:09:24Z

^{Updated 5:02 PM PT - Nov 10th, 2026}

✅ @robobun, your commit 89c65229ee993942154f728c77824efc103cd44e passed in Build #139867! 🎉

🧪 To try this PR locally:

bunx bun-pr 33588

That installs a local version of the PR into your bun-33588 executable, so you can run:

bun-33588 --bun

claude

LGTM — the compile+splitting remap fix addresses my earlier concern and the added tests cover the multi-entry, splitting, and compile paths.

Extended reasoning...

Overview

This PR fixes BuildArtifact.sourcemap returning the wrong artifact when Bun.build() produces more than one JS output. The old code assumed [js, map, js, map, ...] interleaving and assigned the next array element as the sourcemap; the actual layout is [chunks..., sourcemaps..., additional...]. The fix drops the next-element chaining in on_complete_anytask in favor of a two-pass approach: first materialize all BuildArtifact wrappers into output_files_js, then wire each chunk's .sourcemap by looking up output_files_js[source_map_index]. A follow-up commit (0d29725) adds an old_to_new index remap in do_compilation's swap-compact so source_map_index stays valid after compile-mode drops non-entry chunks — this was the regression I flagged in my earlier review, and it's fixed exactly as suggested.

Test additions: 4 parameterized cases in bun-build-api.test.ts (two entrypoints × {splitting on/off} × {linked, external}) asserting each non-sourcemap output's .sourcemap is the kind: "sourcemap" artifact at <path>.map; plus .sourcemap assertions added to the existing compile+external and compile+splitting+external tests in bun-build-compile-sourcemap.test.ts, the latter verifying the linked map's sources includes entry.js (catches wrong-chunk assignment).

Security risks

None. This is purely output-metadata wiring on the JS-thread completion path — no parsing of untrusted input, no auth/crypto/permissions, no new FFI or unsafe blocks (the one unsafe is the pre-existing BuildArtifact.sourcemap.set pattern, unchanged).

Level of scrutiny

Moderate. This is a logic change in the Bun.build() JS-API completion path, not a config tweak, and it interacts with the compile-mode compaction that already produced one subtle bug during review. That said: the mechanism is simple (use the index the bundler already stores instead of positional adjacency), the one interaction I identified was fixed correctly, the old_to_new remap is bounds-safe (old_to_new.len() = pre-compact output_files.len(), which bounds every valid source_map_index), and dropped targets correctly remap to u32::MAX so the second pass skips them.

Other factors

No CODEOWNERS coverage for these paths.
The bug-hunting system found no issues on the current revision.
My earlier review's only finding is resolved; the only commit since the fix is a CI retrigger.
Existing single-entry .sourcemap tests (BuildArtifact properties sourcemap, sourcemap: true with outdir) continue to exercise the unchanged happy path.

robobun · 2026-07-07T04:40:12Z

Status: the fix is pushed (8b911b4). It waits for CI and for a review.

Reproduction on a debug build of main (af566a38e5) and on bun 1.4.3-canary:

// a.ts and b.ts hold one console.log() line each
const r = await Bun.build({ entrypoints: ["./a.ts", "./b.ts"], sourcemap: "linked" });
for (const o of r.outputs) console.log(o.path, "->", o.sourcemap?.path ?? null);
// ./a.js -> ./b.js         expected: ./a.js.map
// ./b.js -> ./a.js.map     expected: ./b.js.map
// ./a.js.map -> null
// ./b.js.map -> null

With this PR the script prints ./a.js -> ./a.js.map and ./b.js -> ./b.js.map.

robobun · 2026-08-08T05:23:37Z

Issue #37184 reports another trigger for this same defect: a single entrypoint that imports CSS with sourcemap: "linked" produces outputs [js, css, js.map], and the next-element pairing assigns the CSS asset as the JS artifact's .sourcemap. Confirmed this PR's index-based pairing fixes that case too.

This branch has conflicts with main now. I rebased the fix onto current main (the artifact.sourcemap.set call was removed on main since the cached value now lives in the wrapper's m_sourcemap slot, so only sourcemap_set_cached is needed) and added a test for the single-entry CSS trigger, verified fail-before on system bun and pass-after on the debug build: https://github.com/oven-sh/bun/tree/farm/3da9e510/sourcemap-pairing-css-asset

robobun · 2026-08-15T10:15:00Z

Ran into the same bug independently (another session handed it off as a separate report); this PR is the same fix, so I am not opening a second one. Two notes for the rebase, since the branch currently conflicts with main:

main no longer has a Rust-side BuildArtifact.sourcemap field (.sourcemap is only the wrapper's m_sourcemap slot now, see the comment above struct BuildArtifact in src/runtime/api/JSBundler.rs), so the two (*artifact).sourcemap.set(..) lines in this diff will not compile there. The sourcemap_set_cached call on its own is the whole fix; the existing "BuildArtifact sourcemap is traced from the owner, not rooted separately" test in test/bundler/bun-build-api.test.ts relies on that being the only reference. The promise.reject(..) return shape in on_complete also changed on main (One termination signal, one fold: Err(Thrown) always means an exception is pending, and each event-loop dispatcher takes it in one place #37275).

The problem is not limited to 2+ entrypoints or splitting. Any chunk without a sourcemap sitting between a JS chunk and the .map files triggers it, so a single entrypoint that imports CSS is affected too. With bun 1.4.0:

// entry.js: import "./a.css"; console.log(1)
const r = await Bun.build({ entrypoints: ["./entry.js"], sourcemap: "external" });
r.outputs.map(o => `${o.kind} ${o.path} -> ${o.sourcemap?.path ?? null}`);
// [ "entry-point ./entry.js -> ./entry.css",   <- the CSS asset, expected ./entry.js.map
//   "asset ./entry.css -> null",
//   "sourcemap ./entry.js.map -> null" ]

Might be worth one extra case in the new describe.each so the single-entrypoint path is covered as well.

The two conflicts are in src/runtime/api/js_bundle_completion_task.rs and test/bundler/bun-build-api.test.ts. This merge takes main for every file. The next commit applies the fix to main's code.

`on_complete` stored the next element of `outputs` as the `.sourcemap` of each output that has a source map. The output list is `[chunks, source maps and bytecode, additional files]`, so the next element is the map only when the build has one chunk. - `on_complete` walks the list from the last file to the first and stores the wrapper of the file at `source_map_index`. It stores only the wrapper of a file of kind `sourcemap`. - `do_compilation` sets the `source_map_index` of the entry point to the position of its map after the compaction, or to `u32::MAX` when the map is not kept. - The standalone HTML filter asserts that no kept file names another file by its position. - `BuildArtifact.sourcemap` is declared as `BuildArtifact | null` again: native code stores only the wrapper of a source map.

robobun · 2026-11-10T18:14:59Z

This PR has a new diff as of 8b911b4. It replaces the version from July, which conflicted with main.

The fix is at the same two sites, on_complete and do_compilation. The mechanism is new: one reverse pass over the outputs and a remap of the position of the executable's map. There is no second loop and no index table.
It also covers the case from BuildArtifact.sourcemap points at a CSS asset in single-entry builds #37184 (one entry point that imports CSS) and compile with an HTML entry point before the JS entry point.
The reviews and the two review threads of 2026-07-07 are about the July version.

The description has the measurements and the list of tests.

claude

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

The compile + splitting stale-index concern from my earlier review is addressed by the entry_at/entry_source_map_at remap in do_compilation. Beyond the inline findings, I also checked the reverse walk in on_complete for sparse-array or ordering problems (the array is preallocated with create_empty_array(len) and the list builder always places a map after its chunk, so get_direct_index sees the wrapper), and the standalone HTML filter in generateChunksInParallel.rs (only HTML and Sourcemap files survive, neither of which carries an index, so the release build needs no remap there). I did not run the test suite or the BUN_JSC_validateExceptionChecks=1 check named in the description.

Extended reasoning...

The change rewires how BuildArtifact.sourcemap is assigned in on_complete (lookup by source_map_index, walked last to first) and remaps the executable's indices after do_compilation compacts the output list, plus two debug asserts, a bindgen return-type narrowing and new tests; no security-sensitive surface. Two confirmed findings are posted inline (a debug-only panic path for compile aot and a certified-silent sourcemap write failure), so a human still needs to weigh those; the note above records what else was examined and ruled out this run.

The other files of the list are gone once the executable is written, so the kept file names none of them by position.

claude

I re-reviewed the latest push and found no new bugs; the new take_executable_file in src/runtime/cli/compile_command/build.rs clears the three position fields on the file finish_compilation keeps, which covers the compile: { aot: true } path I flagged earlier. Because this changes the artifact graph that every Bun.build caller observes (and the invariant that source_map_index survives every list compaction), a human look is still worthwhile.

What was reviewed:

The reverse loop in on_complete: output_files_js is pre-sized by create_empty_array, so filling it last-to-first and reading a later index with getDirectIndex is sound (a hole reads back as a non-cell and is skipped); result is only held across non-allocating calls before put_index.
The do_compilation swap-compact: the entry always precedes its map in the list, so entry_at < entry_source_map_at, and the fallback to u32::MAX when the map write fails matches the new unwritable-map test.
packages/bun-types/bun.d.ts already declares sourcemap: BuildArtifact | null, so the narrowed .bind.ts type needs no .d.ts change.
Not done here: running the new tests against the unfixed build to confirm they fail for the right reason (the PR description claims 24 fail on main; I did not execute them).

Extended reasoning...

The change rewires how BuildArtifact.sourcemap is assigned in src/runtime/api/js_bundle_completion_task.rs (reverse iteration keyed on source_map_index instead of next-element chaining), remaps the entry's indices after the compile-path compaction, clears positions on the CLI compile product in src/runtime/cli/compile_command/build.rs, adds two debug_asserts, narrows a bindgen return type, and adds a parameterized test matrix plus compile tests. It touches no security-sensitive surface. The latest commit addresses the aot-path assert concern raised in the prior run, and no third-party objection is outstanding (coderabbitai threads were resolved by a non-author). It is not approved outright because the fix spans three list-compaction sites in the bundler with release-build behavior that silently yields null when an index is stale, and the fail-on-unfixed-build claim was not verified by running tests.

github-actions Bot added the claude label Jul 7, 2026

coderabbitai Bot reviewed Jul 7, 2026

View reviewed changes

Comment thread src/runtime/api/js_bundle_completion_task.rs Resolved

claude Bot reviewed Jul 7, 2026

View reviewed changes

Comment thread src/runtime/api/js_bundle_completion_task.rs Resolved

ci: retrigger

6317458

claude Bot reviewed Jul 7, 2026

View reviewed changes

maxmilton mentioned this pull request Aug 8, 2026

BuildArtifact.sourcemap points at a CSS asset in single-entry builds #37184

Open

robobun mentioned this pull request Oct 17, 2026

Bun.build: hold the metafile in its artifact when there is no outdir #45169

Open

robobun mentioned this pull request Nov 1, 2026

sourcemap: ignore a <file>.map whose debugId is not the debug id of the file #47628

Open

robobun mentioned this pull request Nov 9, 2026

docs, bun-types: correct the Bun.build sourcemap, banner and footer descriptions #42550

Open

robobun added 2 commits November 10, 2026 17:02

Merge branch 'main' into farm/fbce87c4/fix-buildartifact-sourcemap-link

21e5b50

The two conflicts are in src/runtime/api/js_bundle_completion_task.rs and test/bundler/bun-build-api.test.ts. This merge takes main for every file. The next commit applies the fix to main's code.

robobun changed the title ~~bundler: fix BuildArtifact.sourcemap pointing at wrong output for multi-entry builds~~ Bun.build: set BuildArtifact.sourcemap from source_map_index, not from the next output Nov 10, 2026

claude Bot reviewed Nov 10, 2026

View reviewed changes

Comment thread src/runtime/api/js_bundle_completion_task.rs Resolved

Comment thread test/bundler/bun-build-compile-sourcemap.test.ts Resolved

compile: clear the positions on the file that stands for the executable

89c6522

The other files of the list are gone once the executable is written, so the kept file names none of them by position.

claude Bot reviewed Nov 10, 2026

View reviewed changes

Navigation Menu

Repository navigation

Bun.build: set BuildArtifact.sourcemap from source_map_index, not from the next output - #33588

Bun.build: set BuildArtifact.sourcemap from source_map_index, not from the next output#33588
robobun wants to merge 6 commits into
mainfrom
farm/fbce87c4/fix-buildartifact-sourcemap-link

robobun commented Jul 7, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented Jul 7, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot left a comment

Uh oh!

Uh oh!

Uh oh!

robobun commented Jul 7, 2026 •

edited

Loading

Uh oh!

claude Bot left a comment

Uh oh!

robobun commented Jul 7, 2026 •

edited

Loading

Uh oh!

robobun commented Aug 8, 2026

Uh oh!

robobun commented Aug 15, 2026

Uh oh!

robobun commented Nov 10, 2026

Uh oh!

claude Bot left a comment

Uh oh!

Uh oh!

Uh oh!

claude Bot left a comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

robobun commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Background

Downsides

Uh oh!

coderabbitai Bot commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

robobun commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

claude Bot left a comment

Choose a reason for hiding this comment

Overview

Security risks

Level of scrutiny

Other factors

Uh oh!

robobun commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

robobun commented Aug 8, 2026

Uh oh!

robobun commented Aug 15, 2026

Uh oh!

robobun commented Nov 10, 2026

Uh oh!

claude Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

claude Bot left a comment

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

robobun commented Jul 7, 2026 •

edited

Loading

coderabbitai Bot commented Jul 7, 2026 •

edited

Loading

robobun commented Jul 7, 2026 •

edited

Loading

robobun commented Jul 7, 2026 •

edited

Loading